#+TITLE: Mailing Lists
#+AUTHOR:Joshua Branson
#+OPTIONS: H:10
#+STARTUP: overview

* The Problem
  
  Many software projects communicate and develop software via public
  email lists (also known as mailing lists) instead of using web
  interfaces like Github.  This usually confuses young developers,
  because they generally prefer a web based workflow (like Github),
  which is often seen as easier to use. However, more seasoned
  developers find web workflows restricting.  Sites like "Github.com"
  force developers to use one, and /only one/ development workflow.
  This can be annoying for developers, who want to help several
  programming projects, because they have to learn how to use a
  "Github" workflow with a "FIXME add another site here".  That is why
  seasoned software developers generally prefer email lists; email
  lists lets developers cultivate their editing workflow.
  
  Furthermore, web based workflows force the separation of software
  projects in different and sometimes distant compartments, which may
  hamper communication between software projects from different web
  sites. For example, suppose the authors of a popular JavaScript
  library, which is hosted on Github, plan to improve their JavaScript
  library by make a breaking API change.  Usually the authors, will
  gather feedback from other projects that depend on their library,
  before making this API change.  The JavaScript authors begin to
  notify all such projects on Github, "FIXME add another site", "etc",
  which may mean logging into many different web workflows, and filing
  a bug report with each project.  Conversely, when glibc planned on
  making a significant and breaking API change, they just sent an
  email to the glibc mailing list, and CC-ed all the other relevant
  mailing lists.
  
  Now that the reader has a beginning introduction to the benefits of
  an email software developmental workflow, the reader is also
  probably interested in using such work flows.  To get started,
  consider that software developers' send and receive hundreds of
  emails per day, and developers needed a reliable method to sort
  through these numerous emails.  The answer lies in the email header
  "List-Id".  When a computer user sends an email to a mailing list, a
  program (usually GNU Mailman), on the remote server, adds the email
  header "List-Id".  Then the program forwards the email to the other
  users that are subscribed to the email list.  Developers can then
  filter email via the "List-Id" header, because its content does not
  change; its consistency is guaranteed.
  
  Please consider teaching your email provider (dismail.de, or
  riseup.net, etc), to filter your mailing list emails into the
  appropriate folder, because your email provider can do this sort of
  filtering much faster and more continuously than your email client.
  
  However, this is only part of the solution, because mailing list
  users also ought to specify where followup emails should go.  You
  can use the "[[info:message#Mailing Lists][Mail-Follow-up-To"]] for this.  Mail-Followup-to lets the
  poster alert the rest of the mailing lists that follow up emails
  should go to just the /mailing list/ *or* /to the mailing list and
  the poster./ [fn:1]

* Footnotes

[fn:1]  Regretably, the "List-Id", email header cannot do the job of
the "Mail Followup To." Follow ups to mailing list posts that are sent
directly to the poster, do not contain this header.  Only emails that
are sent directly to the mailing list contain the header "List-Id",
because the /only/ mailing list program (usually GNU Mailman) has the
ability to add the "List-Id" header.
